Software Engineering for HPC — Appunti TiTilda

Introduction

This documents contains a brief overview of all the techniques and procedures used to support robust software creation and such. Related document.

A software engineer job is to architecture and organize work on a complex program in order to have it completed efficiently while preventing errors. This is impossible in reality so software engineers also needs to know how to handle problems, regressions and such.

Doftware engineers are made a different kind of engineers: they do not work on tangible things, they cannot (usually) touch their products. Also, software is very malleable compared to tangible stuff, it can evolve much quickly.

There are multiple ways to organize software development: code & fix, waterfall, iterative, agile, devops and much more. All those methods usually comprise multiple phases: feasibility study/project estimation, requirement analysis and specification, design, coding/unit testing, integration/system testing and maintenance. Those phases can be partially overlapping and or repeated ina loop until the final product is finished.

High Performance Computing (HPC)

HPC is the name of the field that encompasses the study of the usage of big megachonk computers in order to, usually, solve large problems or simulations, process large amount of data and such. HPC computations are usually split over a big cluster of computers, therefore efficient communication between them is essential (and, also, very sensitive because it can cause lots of errors).

A good HPC software must satisfy a few requirements:

• correctness: the software must correctly reflect the model of the reality we want to work on;
• performance: the software must make efficient use of the resources it has access to;
• portability: the software can be moved from a machine to another without much trouble;
• maintainability: the software must follow the following principles:
  • operabiity: the software must be easy to use;
  • simplicity: the software must be easy to understand;
  • evolvability: the software must be easy to modify as new requirements emerge;
• reliability: the software must have a low probability of experiencing failures (termination of the ability of the program to do what it is supposed to do), faults (defects found in production, can be hardware, software or configuration errors) or defects (non-compliance with the specification);
• scalability: the software must handle well load increases.

Requirement engineering

Requirement engineering is the “science” that study how to specify the requirements a software product must follow. In order to plan the development of a bit software product, one must define the goals (what are the final objectives), the domain assumptions (what we assume as true about the context and on how the users will interact with the product) and the requirements (what will the software do and how, in response to what).

Obviously, if the domain requirements are incorrect, the software may not work correctly (in the context it has been deployed).

The requirements be functional (what whe software must do) unfeasible functional (what is not under control of the software but it is necessary for the entire system to work), non functional (how the software should do its job) and technical/constraints (how the software must be built).

A good requirement statement should consern only one thing (otherwise there are multiple requirements packed together), should be non-ambiguous, should be testable and achieveable by the software.

In order to effectively extract good requirements from an high level description of the task the software should do, one should tell himself a brief fictional scenario whre the user interact with the software, just like a simulation. The idea is to predict how the software will interact with the world in order to doscover all issues “early”.

Other tools used to extract requirements may be task observations and surveys.

Since a functional requirement may be really complex to describe, the use cases are used to keep a fixed structure. A single use case is comprised of participating actors (who is in charge of the interaction withthe software), entry condition (when the use case starts), flow of events (what happens when the use case is actuated), exit condition (when the use case is no longer active), exceptions (what kind of errors may emerge and how they should be handled) and special requirement (constraints and non functional requirements related to the use case).

A good use case must respect a few requirements itself:

• The use case must be named with a verb that indicates what the user is trying to do
• The actors must have descriptive names
• The steps must be written with active verbs, not passive
• The casual relationship between steps in a use case must be clear
• There must be a use case for each kind of transaction
• All the exceptions must be described separately
• Use cases must not span over two/three pages
• The steps performed by actors and the ones performed by the system should be easily distinguishable

The interaction between use cases and actors is described with UML diagrams.

All the requirement engineering process leads to the final result: the RASD (Requirement Analysis and Specification Document). The structure of the RASD is the following

• Introduction
  • Purpose
  • Scope
  • Definitions, acronyms, abbreviations
  • Reference documents
  • Overview
• Overall description
  • Scenarios
  • User characteristics
  • Analysis of phenomena
  • Use cases
  • Requirements
  • Domain assumptions
• Bibliography

Software design

Software design is the decision about how the software should accomplish its job. Software architecture (i.e. the sum of all the decisions taken while designing software) is composed by a set of structures:

• Components and connectors: describes how the various software modules will expose functionalities (or connect to other exposed ones)
• Module: describes the structure of the software
• Deployment: describes the execution environment

To be continued

Ultima modifica:

Scritto da: Andrea Oggioni